# Chapter 6. Managing Filesystems, Swap, and Devices

#### Contents:

Managing Filesystems
Managing Swap Space
Device Files

You probably created filesystems and swap space when you first installed Linux (most distributions help you do the basics). Here is a chance to fine-tune these resources. Most of the time, you do these things shortly after installing your operating system, before you start loading up your disks with fun stuff. But occasionally you will want to change a running system, in order to add a new device or perhaps upgrade the swap space when you upgrade your RAM.

## 6.1. Managing Filesystems

To Unix systems, a filesystem is some device (such as a hard drive, floppy, or CD-ROM) that is formatted to store files. Filesystems can be found on hard drives, floppies, CD-ROMs, and other storage media that permit random access. (Note: a tape allows only sequential access, and therefore can't contain a filesystem per se.)

The exact format and means by which files are stored is not important; the system provides a common interface for all filesystem types it recognizes. Under Linux, filesystem types include the Second Extended filesystem, or ext2fs, which you probably use to store Linux files; the MS-DOS filesystem, which allows files on MS-DOS partitions and floppies to be accessed under Linux; and several others, including the ISO 9660 filesystem used by CD-ROM.

Each of these filesystem types has a very different underlying format for storing data. However, when you access any filesystem under Linux, the system presents the data as files arranged into a hierarchy of directories, along with owner and group IDs, permissions bits, and the other characteristics you're familiar with.

In fact, information on file ownership, permissions, and so forth is provided only by filesystem types that are meant to be used for storing Linux files. For filesystem types that don't store this information, the kernel drivers used to access these filesystems "fake" the information. For example, the MS-DOS filesystem has no concept of file ownership; therefore, all files are presented as if they were owned by root. This way, above a certain level, all filesystem types look alike, and each file has certain attributes associated with it. Whether or not these data are actually used in the underlying filesystem is another matter altogether.

As the system administrator, you need to know how to create filesystems should you want to store Linux files on a floppy or add additional filesystems to your hard drives. You also need to know how to use the various tools to check and maintain filesystems should data corruption occur. Also, you must know the commands and files used to access filesystems, for example, those on floppy or CD-ROM.

### 6.1.1. Filesystem Types

Table 6-1 lists the filesystem types supported by the Linux kernel as of Version 2.2.2. New filesystem types are always being added to the system, and experimental drivers for several filesystems not listed here are available. To find out what filesystem types your kernel supports, look at the kernel source tree, in the directory /usr/src/linux/fs. You can select which filesystem types to support when building your kernel; see the section "Section 7.4.2, "Building the Kernel"" in Chapter 7, "Upgrading Software and the Kernel".

#### Table 6-1. Linux Filesystem Types

Filesystem | Type | Description
--- | --- | ---
Second Extended filesystem | ext2 | Most common Linux filesystem
Minix filesystem | minix | Original Minix filesystem; rarely used
ROM filesystem | romfs | A tiny read-only filesystem, mainly used for ramdisks
Network File System (NFS) | NFS | Allows access to remote files on network
UMSDOS filesystem | umsdos | Installs Linux on an MS-DOS partition
DOS-FAT filesystem | msdos | Accesses MS-DOS files
VFAT filesystem | vfat | Accesses Windows 95/98 files
NT filesystem | ntfs | Accesses Windows NT files
HPFS filesystem | hpfs | OS/2 filesystem
/proc filesystem | proc | Provides process information for `ps`
ISO 9660 filesystem | iso9660 | Used by most CD-ROMs
Joliet filesystem | iso9660 | An extension to the ISO 9660 filesystem that can handle Unicode filenames
Xenix filesystem | xenix | Accesses files from Xenix
System V filesystem | sysv | Accesses files from System V variants
Coherent filesystem | coherent | Accesses files from Coherent
UFS filesystem | ufs | Accesses files from UFS filesystems, like those on SunOS or BSD
ADFS filesystem | adfs | Accesses files from Acorn partitions
AFFS filesystem | affs | Accesses files from standard AmigaOS filesystem partitions
Apple Mac filesystem | hfs | Accesses files from Apple Macintosh
QNX4 filesystem | qnx4 | Accesses files from a QNX4 partitions
Novell filesystem | ncpfs | Accesses files from a Novell server
SMB filesystem | smbfs | Accesses files from a Windows for Workgroups or Windows NT server

Each filesystem type has its own attributes and limitations; for example, the MS-DOS filesystem restricts filenames to eight characters plus a three-character extension and should be used only to access existing MS-DOS floppies or partitions. For most of your work with Linux, you'll use the Second Extended filesystem, which was developed primarily for Linux and supports 256-character filenames, a 4-terabyte maximum filesystem size, and a slew of other goodies. Earlier Linux systems used the Extended filesystem (no longer supported) and the Minix filesystem. (The Minix filesystem was originally used for several reasons. First of all, Linux was originally cross-compiled under Minix. Also, Linus was quite familiar with the Minix filesystem, and it was straightforward to implement in the original kernels.) The Xia filesystem is no longer supported.

You will rarely need the ROM filesystem, which is very small, does not support write operations, and is meant to be used in ramdisks at system configuration, startup time, or even in EPROMS.

The UMSDOS filesystem is used to install Linux under a private directory of an existing MS-DOS partition. This is a good way for new users to try out Linux without repartitioning. The DOS-FAT filesystem, on the other hand, is used to access MS-DOS files directly. Files on partitions created with Windows 95 or 98 can be accessed via the VFAT filesystem, while the NTFS filesystem lets you access Windows NT filesystems. The HPFS filesystem is used to access the OS/2 filesystem.

With the CVF-FAT extension to the DOS-FAT filesystem, it is possible to access partitions that have been compressed with DoubleSpace/DriveSpace from Microsoft or Stacker from Stac. See the file Documentation/filesystems/fat_cvf.txt in the Linux kernel sources for further details.

/proc is a virtual filesystem; that is, no actual disk space is associated with it. See the /proc filesystem in Chapter 5, "Essential System Management".[27]

> [27]Note that the /proc filesystem under Linux is not the same format as the /proc filesystem under SVR4 (say, Solaris 2.x). Under SVR4, each running process has a single "file" entry in /proc, which can be opened and treated with certain ioctl() calls to obtain process information. On the contrary, Linux provides most of its information in /proc through read() and write() requests.

The ISO 9660 filesystem (previously known as the High Sierra Filesystem and abbreviated hsfs on other Unix systems), is used by most CD-ROMs. Like MS-DOS, this filesystem type restricts filename length and stores only limited information about each file. However, most CD-ROMs provide the Rock Ridge Extensions to ISO 9660, which allow the kernel filesystem driver to assign long filenames, ownerships, and permissions to each file. The net result is that accessing an ISO 9660 CD-ROM under MS-DOS gives you 8.3-format filenames, but under Linux gives you the "true," complete filenames.

In addition, Linux now supports the Microsoft Joliet extensions to ISO 9660 which can handle long filenames made up of Unicode characters. This is not widely used now but may become valuable in the future, because Unicode has been accepted internationally as the standard for encoding characters of scripts world-wide.

Next, we have four filesystem types corresponding to other Unix variants found on the personal computer: UFS, Xenix, System V, and Coherent. (The latter three are actually handled by the same kernel driver, with slightly different parameters for each). If you have filesystems created under one of these formats, you'll be able to access the files from Linux.

Finally, there is a slew of filesystems for accessing data on partitions; these are created by operating systems other than the DOS and Unix families. Those filesystems support the Acorn Disk Filing System (ADFS), the AmigaOS filesystems (no floppy disk support except on Amigas), the Apple Mac HFS, and the QNX4 filesystem. Most of the specialized filesystems are useful only on certain hardware architectures; for instance, you won't have hard disks formatted with the Amiga FFS filesystem in an Intel machine. If you need one of those drivers, please read the information that comes with them; some are only in an experimental state.

### 6.1.2. Mounting Filesystems

In order to access any filesystem under Linux, you must mount it on a certain directory. This makes the files on the filesystem appear as though they reside in the given directory, allowing you to access them.

The `mount` command is used to do this and usually must be executed as root. (As we'll see later, ordinary users can use `mount` if the device is listed in the /etc/fstab file.) The format of this command is:

>     mount -t type device mount-point

where type is the type name of the filesystem as given in Table 6-1, device is the physical device where the filesystem resides (the device file in /dev), and mount-point is the directory on which to mount the filesystem. You have to create the directory before issuing `mount`.

For example, if you have a Second Extended filesystem on the partition /dev/hda2, and wish to mount it on the directory /mnt, use the command:

>     mount -t ext2 /dev/hda2 /mnt

If all goes well you should be able to access the filesystem under /mnt. Likewise, to mount a floppy that was created on a Windows system and therefore is in DOS format, you use the command:

>     mount -t msdos /dev/fd0 /mnt

This makes the files available on an MS-DOS format floppy under /mnt.

There are many options to the `mount` command, which can be specified with the -o switch. For example, the MS-DOS and ISO 9660 filesystems support "auto-conversion" of text files from MS-DOS format (which contain CR-LF at the end of each line), to Unix format (which contain merely a newline at the end of each line). Using a command such as:

>     mount -o conv=auto -t msdos /dev/fd0 /mnt

turns on this conversion for files that don't have a filename extension that could be associated with a binary file (such as .exe, .bin, and so forth).

One common option to mount is -o ro (or, equivalently, -r), which mounts the filesystem as read-only. All write access to such a filesystem is met with a "permission denied" error. Mounting a filesystem as read-only is necessary for media like CD-ROMs that are nonwritable. You can successfully mount a CD-ROM without the -r option, but you'll get the annoying warning message:

>     mount: block device /dev/cdrom is write-protected, mounting read-only

Use a command such as:

>     mount -t iso9660 -r /dev/cdrom /mnt

instead. This is also necessary if you are trying to mount a floppy that has the write-protect tab in place.

The `mount` manual page lists all available mounting options. Not all are of immediate interest, but you might have a need for some of them, someday.

The inverse of mounting a filesystem is, naturally, unmounting it. Unmounting a filesystem has two effects: it synchronizes the system's buffers with the actual contents of the filesystem on disk, and it makes the filesystem no longer available from its mount point. You are then free to mount another filesystem on that mount point.

Unmounting is done with the `umount` command (note that the first "n" is missing from the word "unmount"), as in:

>     umount /dev/fd0

to unmount the filesystem on /dev/fd0. Similarly, to unmount whatever filesystem is currently mounted on a particular directory, use a command such as:

>     umount /mnt

It is important to note that removable media, including floppies and CD-ROMs, should not be removed from the drive or swapped for another disk while mounted. This causes the system's information on the device to be out of sync with what's actually there and could lead to no end of trouble. Whenever you want to switch a floppy or CD-ROM, unmount it first, using the `umount` command, and then remount the device.

Reads and writes to filesystems on floppies are buffered in memory as they are for hard drives. This means that when you read or write data to a floppy, there may not be any immediate drive activity. The system handles I/O on the floppy asynchronously and reads or writes data only when absolutely necessary. So if you copy a small file to a floppy, but the drive light doesn't come on, don't panic; the data will be written eventually. You can use the `sync` command to force the system to write all filesystem buffers to disk, causing a physical write of any buffered data. Unmounting a filesystem makes this happen as well.

If you wish to allow mortal users to mount and unmount certain devices, you have two options. The first option is to include the `user` option for the device in /etc/fstab (described later in this section). This allows any user to use the `mount` and `umount` command for a given device. Another option is to use one of the mount frontends available for Linux. These programs run setuid root and allow ordinary users to mount certain devices. In general, you wouldn't want normal users mounting and unmounting a hard drive partition, but use of CD-ROM and floppy drives might be more lenient on your system.

There are quite a few things that can go wrong when attempting to mount a filesystem. Unfortunately, the `mount` command will give you the same error message in response to a number of problems:

>     mount: wrong fs type, /dev/cdrom already mounted, /mnt busy, or other error

`wrong fs type` is simple enough: this means that you may have specified the wrong type to `mount`. If you don't specify a type, `mount` tries to guess the filesystem type from the superblock (this only works for minix, ext, ext2, xia and iso9660). If `mount` still cannot determine the type of the filesystem, it tries all the types for which drivers are included in the kernel (as listed in /proc/filesystems). If this still does not lead to success, `mount` fails. device `already mounted` means just that: the device is already mounted on another directory. You can find out what devices are mounted, and where, using the `mount` command with no arguments:

>     rutabaga# mount
>     /dev/hda2 on / type ext2 (rw)
>     /dev/hda3 on /msdos type msdos (rw)
>     /dev/cdrom on /cdrom type iso9660 (ro)
>     /proc on /proc type proc (rw,none)

Here, we see two hard-drive partitions, one of type ext2 and the other of type msdos, a CD-ROM mounted on /cdrom, and the /proc filesystem. The last field of each line (for example, `(rw)`) lists the options under which the filesystem is mounted. More on these soon. Note that the CD-ROM device is mounted in /cdrom. If you use your CD-ROM often, it's convenient to create the directory /cdrom and mount the device there. /mnt is generally used to temporarily mount filesystems such as floppies.

The error mount-point `busy` is rather odd. Essentially, it means there is some activity taking place under mount-point that prevents you from mounting a filesystem there. Usually, this means that there is an open file under this directory, or some process has its current working directory beneath mount-point. When using `mount`, be sure your root shell is not within mount-point; do a `cd /` to get to the top-level directory. Or, another filesystem could be mounted with the same mount-point. Use `mount` with no arguments to find out.

Of course, `other error` isn't very helpful. There are several other cases in which `mount` could fail. If the filesystem in question has data or media errors of some kind, `mount` may report it is unable to read the filesystem's superblock, which is (under Unix-like filesystems) the portion of the filesystem that stores information on the files and attributes for the filesystem as a whole. If you attempt to mount a CD-ROM or floppy, and there's no CD-ROM or floppy in the drive, you will receive an error message such as:

>     mount: /dev/cdrom is not a valid block device

Floppies are especially prone to physical defects (more so than you might initially think), and CD-ROMs suffer from dust, scratches, and fingerprints, as well as being inserted upside-down--that kind of thing. (If you attempt to mount your Stan Rogers CD as ISO 9660 format, you will likely run into similar problems.)

Also, be sure the mount point you're trying to use (such as /mnt) exists. If not, you can simply create it with the `mkdir` command.

If you have problems mounting or accessing a filesystem, data on the filesystem may be corrupt. There are several tools that help repair certain filesystem types under Linux; see "Section 6.1.5, "Checking and Repairing Filesystems"" later in this chapter.

The system automatically mounts several filesystems when the system boots. This is handled by the file /etc/fstab, which includes an entry for each filesystem that should be mounted at boot time. Each line in this file is of the format:

>     device mount-point type options

Here, device, mount-point, and type are equivalent to their meanings in the `mount` command, and options is a comma-separated list of options to use with the -o switch to `mount`.

A sample /etc/fstab is shown here:

>     # device        directory       type      options
>     /dev/hda2       /               ext2      defaults
>     /dev/hda3       /msdos          msdos     defaults
>     /dev/cdrom      /cdrom          iso9660   ro
>     /proc           /proc           proc      none

>     /dev/hda1       none            swap      sw

The last line of this file specifies a swap partition. This is described in the section "Section 6.2, "Managing Swap Space"." later in this chapter.

The `mount` manual page lists the possible values for options; if you wish to specify more than one option, you can list them with separating commas and no whitespace, as in:

>     /dev/cdrom      /cdrom          iso9660   ro,user

The `user` option allows users other than root to mount the filesystem. If this option is present, a user can execute a command such as:

>     mount /cdrom

to mount the device. Note that if you specify only a device or mount point (not both) to `mount`, it looks up the device or mount point in /etc/fstab and mounts the device with the parameters given there. This allows you to mount devices listed in /etc/fstab with ease.

The option `defaults` should be used for most filesystems; it enables a number of other options, such as `rw` (read-write access), `async` (buffer I/O to the filesystem in memory asynchronously), and so forth. Unless you have a specific need to modify one of these parameters, use `defaults` for most filesystems, and `ro` for read-only devices such as CD-ROMs. Another potentially useful option is `umask` that lets you set the default mask for the permission bits, something that is especially useful with some foreign filesystems.

The command `mount -a` will mount all filesystems listed in /etc/fstab. This command is executed at boot time by one of the scripts found in /etc/rc.d, such as rc.sysinit (or wherever your distribution stores its configuration files). This way, all filesystems listed in /etc/fstab will be available when the system starts up; your hard drive partitions, CD-ROM drive, and so on will all be mounted.

There is an exception to this: the root filesystem. The root filesystem, mounted on /, usually contains the file /etc/fstab as well as the scripts in /etc/rc.d. In order for these to be available, the kernel itself must mount the root filesystem directly at boot time. The device containing the root filesystem is coded into the kernel image and can be altered using the `rdev` command (see "Section 5.2.1, "Using a Boot Floppy"" in Chapter 5, "Essential System Management"). While the system boots, the kernel attempts to mount this device as the root filesystem, trying several filesystem types in succession (first Minix, then Extended, and so forth). If at boot time, the kernel prints an error message such as:

>     VFS: Unable to mount root fs

one of the following has happened:

- The root device coded into the kernel is incorrect.

- The kernel does not have support compiled in for the filesystem type of the root device. (See "Section 7.4.2, "Building the Kernel"" in Chapter 7, "Upgrading Software and the Kernel" for more details. This is usually relevant only if you build your own kernel.)

- The root device is corrupt in some way.

In any of these cases, the kernel can't proceed and panics. See "Section 8.6, "What to Do in an Emergency"" in Chapter 8, "Other Administrative Tasks", for clues on what to do in this situation. If filesystem corruption is the problem, this can usually be repaired; see "Section 6.1.5, "Checking and Repairing Filesystems"" later in this chapter.

A filesystem does not need to be listed in /etc/fstab in order to be mounted, but it does need to be listed there in order to be mounted "automatically" by `mount -a`, or to use the `user` mount option.

### 6.1.3. Automounting Devices

If you need to access a lot of different filesystems, especially networked ones, you might be interested in a fairly new addition to the Linux kernel: the automounter. This is a combination of kernel functionality, a daemon, and some configuration files that automatically detect when somebody wants to access a certain filesystem and mounts the filesystem transparently. When the filesystem is not used for some time, the automounter automatically unmounts it in order to save resources like memory and network throughput.

If you want to use the automounter, you first need to turn this feature on when building your kernel. (See "Section 7.4.2, "Building the Kernel"" in Chapter 7, "Upgrading Software and the Kernel" for more details.) You will also need to enable the NFS option.

Next, you need to start the automount daemon. Since this feature is quite new, your distribution might not yet have it. Look for the directory /usr/lib/autofs, if it is not there, you will need to get the autofs package from your friendly Linux archive and compile and install it according to the instruction.

You can automount filesystems wherever you like, but for simplicity's sake, we will assume here that you want to automount all filesystems below one directory which we will call /automount here. If you want your automount points to be scattered over your filesystem, you will need to use multiple `automount` daemons.

If you have compiled the autofs package yourself, it might be a good idea to start by copying the sample configuration files that you can find in sample directory, and adapt them to your needs. To do this, copy the files sample/auto.master and sample/auto.misc into the /etc directory, and the file sample/rc.autofs under the name `autofs` wherever your distribution stores its boot scripts. We'll assume here that you use /sbin/init.d.

The first configuration file to edit is /etc/auto.master. This lists all the directories (the so-called mount points) below which the automounter should mount partitions. Since we have decided to use only one partition in this chapter's example, we will need to make only one entry here. The file could look like this:

>     /automount	/etc/auto.misc

This file consists of lines with two entries each, separated by whitespace. The first entry specifies the mount point, and the second entry names a so-called map file that specifies how and where to mount the devices or partitions to be automounted. You need one such map file for each mount point.

In our case, the file /etc/auto.misc looks like the following:

>     cd		-fstype=iso9660,ro	:/dev/scd0
>     floppy		-fstype=auto		:/dev/fd0

Again, this file consists of one-line entries that each specify one particular device or partition to be automounted. The lines have two mandatory and one optional field, separated by whitespaces. The first value is mandatory and specifies the directory, onto which the device or partition of this entry is automounted. This value is appended to the mount point so that the CD-ROM will be automounted onto /automount/cd.

The second value is optional and specifies flags to be used for the `mount` operation. These are equivalent to those for the `mount` command itself, with the exception that the type is specified with the option -fstype= instead of -T.

Finally, the third value specifies the partition or device to be mounted. In our case, we specify the first SCSI CD-ROM drive and the first floppy drive, respectively. The colon in front of the entry is mandatory; it separates the host part from the device/directory part, just as with `mount`. Since those two devices are on a local machine, there is nothing to the left of the colon. If we wanted to automount the directory sources from the NFS server sourcemaster, we would specify something like:

>     sources    -fstype=nfs,soft    sourcemaster:/sources

After editing the configuration files to reflect your system, you can start the automount daemon by issuing (replace the path with the path that suits your system):

>     tigger# /sbin/init.d/autofs start

Since this command is very taciturn, you should check whether the automounter has really started. One way to do this is to issue:

>     tigger# /sbin/init.d/autofs status

but it is difficult to determine from the output whether the automounter is really running. Your best bet, therefore, is to check whether the `automount` process exists:

>     tigger# ps -aux | grep automount

If this command shows the automount process, everything should be all right. If it doesn't, you need to check your configuration files again. It could also be the case that the necessary kernel support is not available: either the automount support is not in your kernel, or you have compiled it as a module but not installed this module. If the latter is the case, you can fix the problem by issuing:

>     tigger# modprobe autofs

When your automounter works to your satisfaction, you might want to put the `modprobe` call as well as the `autofs` call in one of your system's startup configuration files like /etc/rc.local, /sbin/init.d/boot.local or whatever your distribution uses.

If everything is correctly set up, all you need to do is access some directory below the mount point, and the automounter will mount the appropriate device or partition for you. For example, if you type:

>     tigger$ ls /automount/cd

the automounter will automatically mount the CD-ROM, so that `ls` can list its contents. The only difference between normal and automounting is that with automounting you will notice is a slight delay, before the output comes.

In order to conserve resources, the automounter unmounts a partition or device if it has not been accessed for a certain amount of time (the default is five minutes).

The automounter supports a number of advanced options; for example, you do not need to read the map table from a file but can also access system databases or even have the automounter run a program and use this program's output as the mapping data. See the man pages for `autofs` and `automount` for further details.

### 6.1.4. Creating Filesystems

A filesystem can be created using the `mkfs` command. Creating a filesystem is analogous to "formatting" a partition or floppy, allowing it to store files.

Each filesystem type has its own `mkfs` command associated with it--for example, MS-DOS filesystems may be created using `mkfs.msdos`, Second Extended filesystems using `mkfs.ext2`, and so on. The program `mkfs` itself is a frontend that creates a filesystem of any type by executing the appropriate version of `mkfs` for that type.[28]

> [28]Under Linux the `mkfs` command historically created a Minix filesystem. On newer Linux systems, `mkfs` is a frontend for any filesystem type, and Minix filesystems are created using `mkfs.minix`.

When you installed Linux, you may have created filesystems by hand using a command such as `mke2fs`. (If not, then the installation software created the filesystems for you.) In fact, `mke2fs` is equivalent to `mkfs.ext2`. The programs are the same (and on many systems, one is a symbolic link to the other), but the mkfs.fs-type filename makes it easier for `mkfs` to execute the appropriate filesystem-type specific program. If you don't have the `mkfs` frontend, you can use `mke2fs` or `mkfs.ext2` directly.

Assuming that you're using the `mkfs` frontend, a filesystem can be created using this command:

>     mkfs -t type device blocks

where type is the type of filesystem to create, given in Table 6-1, device is the device on which to create the filesystem (such as /dev/fd0 for a floppy), and blocks is the size of the filesystem, in 1024-byte blocks.

For example, to create an ext2 filesystem on a floppy, you use this command:

>     mkfs -t ext2 /dev/fd0 1440

Here, blocks is 1440, which specifies a 1.44-MB, high-density 3.5-inch floppy. You could create an MS-DOS floppy using -t msdos instead.

We can now mount the floppy, as described in the previous section, copy files to it, and so forth. Remember to unmount the floppy before removing it from the drive.

Creating a filesystem deletes all data on the corresponding physical device (floppy, hard-drive partition, whatever). `mkfs` usually does not prompt you before creating a filesystem, so be absolutely sure you know what you're doing.

Creating a filesystem on a hard-drive partition is done exactly as shown earlier, except that you would use the partition name, such as `/dev/hda2`, as the device. Don't try to create a filesystem on a device, such as `/dev/hda`. This refers to the entire drive, not just a single partition on the drive. You can create partitions using `fdisk`, as described in the section "Section 3.1.3, "Creating Linux Partitions"" in Chapter 3, "Installation and Initial Configuration".

You should be especially careful when creating filesystems on hard-drive partitions. Be absolutely sure that the device and size arguments are correct. If you enter the wrong device, you could end up destroying the data on your current filesystems, and if you specify the wrong size, you could overwrite data on other partitions. Be sure that size corresponds to the partition size as reported by Linux `fdisk`.

When creating filesystems on floppies, it's usually best to do a low-level format first. This lays down the sector and track information on the floppy so that its size can be automatically detected using the devices /dev/fd0 or /dev/fd1. One way to do a low-level format is with the MS-DOS FORMAT command; another way is with the Linux program `fdformat`.[29] For example, to format the floppy in the first floppy drive, use the command:

>     rutabaga# fdformat /dev/fd0
>     Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
>     Formatting ... done
>     Verifying ... done

Using the -n option with `fdformat` will skip the verification step.

> [29]Debian users should use `superformat` instead.

Each filesystem-specific version of `mkfs` supports several options you might find useful. Most types support the -c option, which causes the physical media to be checked for bad blocks while creating the filesystem. If bad blocks are found, they are marked and avoided when writing data to the filesystem. In order to use these type-specific options, include them after the -t type option to `mkfs`, as follows:

>     mkfs -t type -c device blocks

To determine what options are available, see the manual page for the type-specific version of `mkfs`. (For example, for the Second Extended filesystem, see `mke2fs`.)

You may not have all available type-specific versions of `mkfs` installed. If this is the case, `mkfs` will fail when you try to create a filesystem of a type for which you have no mkfs.type. Many filesystem types supported by Linux have a corresponding mkfs.type available, somewhere.

If you run into trouble using `mkfs`, it's possible that Linux is having problems accessing the physical device. In the case of a floppy, this might just mean a bad floppy. In the case of a hard drive, it could be more serious; for example, the disk device driver in the kernel might be having problems reading your drive. This could be a hardware problem or a simple matter of your drive geometry being specified incorrectly. See the manual pages for the various versions of `mkfs`, and read the sections in Chapter 3, "Installation and Initial Configuration" on troubleshooting installation problems. They apply equally here.[30]

> [30]Also, the procedure for making an ISO9660 filesystem for a CD-ROM is more complicated than simply formatting a filesystem and copying files. See the CD-Writing HOWTO for more details.

### 6.1.5. Checking and Repairing Filesystems

It is sometimes necessary to check your Linux filesystems for consistency and repair them if there are any errors or lost data. Such errors commonly result from a system crash or loss of power, where the kernel isn't able to sync the filesystem buffer cache with the contents of the disk. In most cases, such errors are relatively minor. However, if the system were to crash while writing a large file, that file may be lost and the blocks associated with it marked as "in use," when in fact there is no file entry corresponding to them. In other cases, errors can be caused by accidentally writing data directly to the hard-drive device (such as /dev/hda), or one of the partitions.

The program `fsck` is used to check filesystems and correct any problems. Like `mkfs`, `fsck` is a frontend for a filesystem-type-specific fsck.type, such as `fsck.ext2` for Second Extended filesystems. (As with `mkfs.ext2`, `fsck.ext2` is a symbolic link to `e2fsck`, either of which you could execute directly if the `fsck` frontend is not installed.)

Use of `fsck` is quite simple; the format of the command is:

>     fsck -t type device

where type is the type of filesystem to repair, as given in Table 6-1, and device is the device (drive partition or floppy) on which the filesystem resides.

For example, to check an `ext2` filesystem on /dev/hda2, you use:

>     rutabaga# fsck -t ext2 /dev/hda2
>     Parallelizing fsck version 1.06 (7-Oct-96)
>     e2fsck 1.06, 7-Oct-96 for EXT2 FS 0.5b, 95/08/09
>     /dev/hda2 is mounted.  Do you really want to continue (y/n)? yes

>     /dev/hda2 was not cleanly unmounted, check forced.
>     Pass 1: Checking inodes, blocks, and sizes
>     Pass 2: Checking directory structure
>     Pass 3: Checking directory connectivity
>     Pass 4: Check reference counts.
>     Pass 5: Checking group summary information.

>     Free blocks count wrong for group 3 (3331, counted=3396).  FIXED
>     Free blocks count wrong for group 4 (1983, counted=2597).  FIXED
>     Free blocks count wrong (29643, counted=30341).  FIXED
>     Inode bitmap differences: -8280.  FIXED
>     Free inodes count wrong for group #4 (1405, counted=1406).  FIXED
>     Free inodes count wrong (34522, counted=34523).  FIXED

>     /dev/hda2: ***** FILE SYSTEM WAS MODIFIED *****
>     /dev/hda2: ***** REBOOT LINUX *****
>     /dev/hda2: 13285/47808 files, 160875/191216 blocks

First of all, note that the system asks for confirmation before checking a mounted filesystem. If any errors are found and corrected while using `fsck`, you'll have to reboot the system if the filesystem is mounted. This is because the changes made by `fsck` may not be propagated back to the system's internal knowledge of the filesystem layout. In general, it's not a good idea to check mounted filesystems.

As we can see, several problems were found and corrected, and because this filesystem was mounted, the system informed us that the machine should be rebooted.

How can you check filesystems without mounting them? With the exception of the root filesystem, you can simply `umount` any filesystems before running `fsck` on them. The root filesystem, however, can't be unmounted while running the system. One way to check your root filesystem while it's unmounted is to use a boot/root floppy combination, such as the installation floppies used by your Linux distribution. This way, the root filesystem is contained on a floppy, and the root filesystem (on your hard drive) remains unmounted, and you can check the hard-drive root filesystem from there. See "Section 8.6, "What to Do in an Emergency"" in Chapter 8, "Other Administrative Tasks" for more details about this.

Another way to check the root filesystem is to mount it read-only. This can be done using the option `ro` from the LILO boot prompt (see the section "Section 5.2.2.3, "Specifying boot time options"" in Chapter 5, "Essential System Management"). However, other parts of your system configuration (for example, the programs executed by /etc/init at boot time) may require write access to the root filesystem, so you can't boot the system normally or these programs will fail. To boot the system with the root filesystem mounted as read-only you might want to boot the system into single-user mode as well (using the boot option `single`). This prevents additional system configuration at boot time; you can then check the root filesystem and reboot the system normally.

To cause the root filesystem to be mounted read-only, you can either use the `ro` boot option, or use `rdev` to set the read-only flag in the kernel image itself.

Many Linux systems automatically check the filesystems at boot time. This is usually done by executing `fsck` from /etc/rc.d/rc.sysinit. When this is done, the system usually mounts the root filesystem initially as read-only, runs `fsck` to check it, and then runs the command:

>     mount -w -o remount /

The -o remount option causes the given filesystem to be remounted with the new parameters; in this case, the -w option (equivalent to -o rw) causes the filesystem to be mounted read-write. The net result is that the root filesystem is remounted with read-write access.

When `fsck` is executed at boot time, it checks all filesystems other than root before they are mounted. Once `fsck` completes, the other filesystems are mounted using `mount`. Check out the files in /etc/rc.d, especially rc.sysinit (if present on your system), to see how this is done. If you want to disable this feature on your system, comment out the lines in the appropriate /etc/rc.d file that execute `fsck`.

There are several options you can pass to the type-specific `fsck`. Most types support the options -a, which automatically confirms any prompts that fsck.type may display; -c, which does bad-block checking, as with `mkfs`; and -v, which prints verbose information during the check operation. These options should be given after the -t type argument to `fsck`, as in:

>     fsck -t type -v device

to run `fsck` with verbose output.

See the manual pages for `fsck` and `e2fsck` for more information.

Not all filesystem types supported by Linux have a `fsck` variant available. To check and repair MS-DOS filesystems, you should use a tool under MS-DOS, such as the Norton Utilities, to accomplish this task. You should be able to find versions of `fsck` for the Second Extended filesystem, Minix filesystem, and Xia filesystem at least.

In the section "Section 8.6, "What to Do in an Emergency"" in Chapter 8, "Other Administrative Tasks", we provide additional information on checking filesystems and recovering from disaster. `fsck` will by no means catch and repair every error to your filesystems, but most common problems should be handled. If you delete an important file, there is currently no easy way to recover it--`fsck` can't do that for you. There is work underway to provide an "undelete" utility in the Second extended filesystem. Be sure to keep backups, or use `rm -i`, which always prompts you before deleting a file.

Copyright © 2001 O'Reilly & Associates. All rights reserved.